Request Types and SubTypes

A request type is the top-level classification of work to be performed. To add a request type:

1. On the Add a New Request Typepane of the page, in the Add New Request Type field, enter a name for the new request type.

   This name should define the type of work at the highest level. For example, you could create a request type named Set Up for all work requests that involve setting up for an event.

   The name you enter must be unique. If you enter a request type that already exists, an error message appears.

2. In the Associate to this Activity Group field, select an activity group to associate this request type with.

   The activity group defines which set of users can create requests of this type. If you do not select an activity group, the request type will be created, but it will not be available for use by any users.

   If you later want to disassociate this request type from the selected activity group, you can do so on the Activity Groups page.

3. If you are interfacing with an external system and want to map this request type to a request type defined in the external system, enter a value in the Associate to this External Request Type ID field.

   For example, if your external system uses exclusively numeric request IDs, you could associate the Set Up request type with the 223-4000 external request ID.

4. Click ADD and then click OK in the confirmation dialog box that opens.

   At the top of the page, additional fields appear to further define the request type.

5. Modify the value in any of the following fields:

   • Tab Order – This numerical value specifies the position of the request type in drop-down menus, where lower numbers are displayed toward the top. Request types with the same tab order value are sorted alphabetically.
   • Allow Parent/Child – This value indicates whether work requests of this type can have parent and child work requests associated with it. If set to No, requests of this type cannot be children or parents of other work requests. If Maintenance Project Type is set to Yes, this value must also be set to Yes.
   • Survey Type – This value indicates whether a survey will be associated with the request type. If you select Yes, the appropriate survey will be sent with all work requests of this type. For more information, see Survey Rules.
   • Default Open Status – This value indicates the request status value that will be automatically assigned to requests of this type upon initial creation. This allows new requests to be assigned an initial status of something other than Open. If no value is specified, the initial status defaults to Open.
   • Key WO Type? - This value indicates whether you can request and issue a key through this request type.
   • Status – This value indicates whether the request type is currently active in the system. Active request types are displayed to users; Inactive request types are not.

   • Push WOs to External System – This value indicates requests of this type are integrated with an external third-party system. Additional configuration options must be setup to configure the system to integrate work orders with an external system.

   • Rename – This value allows you to modify the request type name. If you rename a request type, all historical information will reflect the new request type name.
   • Project Type – This value indicates whether the type can be used as a project type as well as a request type (if the Project module is enabled).
   • Maintenance Project Type – This value indicates that requests of this type should be flagged as being of the maintenance project type (where parent/child work requests are allowed) to allow these requests to be aggregated for searching and reporting. If this value is set to Yes, the Allow Parent/Child value is set to Yes and cannot be modified.
   • Standing WO Type – This value indicates whether requests of this type are classified as standing work orders. Standing work orders are work orders that are kept open for long periods of time, allowing repeated labor, material, and other costs to be charged against them. Setting this flag to Yes allows work orders of this type to be located on the Find Requests page when the user sets the Search Filter criteria to Standing WOs Only.
   • Asset Required Create – This value indicates whether an asset must be specified on all work requests of this type.
   • Asset Required Close – This value indicates whether an asset must be attached to the work order before it can be closed. This can be used instead of the Asset Required Create option in cases where the creator of the work request may not know which asset to attach but the technician completing the work will.
   • Signature Required Complete - This value indicates whether a signature is required to complete work requests of this type.
   • Account String Required Create – For installations using NPFA (Non-Profit Fund Accounting) only, this value indicates whether an account string must be specified on all work requests of this type.
   • Account String Required Close – For installations using NPFA (Non-Profit Fund Accounting) only, this value indicates whether an account string must be specified on the work request before it can be closed.
   • External Request Type ID – This value allows you to define/modify a mapping to a request type ID in an external system.

6. Define one or more request subTypes.

   Every request type must have at least one request subType associated with it. For more information, see Add a New Request SubType.

7. If you want to associate this request type with all properties in a region, scroll down to the bottom of the page, click the Other Options link, click the Select link, and then select a region.

A request subType defines a more granular classification of work below the request type. For example, beneath the Set Up request type, you could define the Meeting and Trade Show subTypes. A subType can only be added beneath a request type. To add a request subType:

1. In the Request Type field, select the request type you want to add the subType to.

   The detail fields for the request type appear.

2. On the Request SubTypes pane of the page, in the Add Request SubType field, enter a name for the new subType.

   This name should further define the type of work. The name you enter must be unique within the request type. If you enter a subType that already exists, an error message appears.

3. If you are interfacing with an external system and want to map this subType to a subType defined in the external system, enter a value in the External SubType ID field.

4. Click ADD.

   The subType is added to the list of subTypes displayed in the yellow pane.

5. Modify the value in any of the standard fields:

   • Status – This value indicates whether the subType is currently active in the system. Active subTypes are displayed to users; Inactive subTypes are not.
   • Tab Order – This numerical value specifies the position of the subType in a drop-down menu, where lower numbers are displayed toward the top. SubTypes with the same tab order value are sorted alphabetically.
   • SubType – This value allows you to rename the subType.
   • Billable? – This value indicates whether the work request will be billable or non-billable by default. The default value is No. If this field is left as the default, the system will verify that there are no existing billable codes for the item. If there are none, the default will be applied. If yes, the system will override the default billable flag.
   • Bill Code – A default Bill Code to be displayed when creating a work request. This code must already exist. For more information see Adding a Bill Code.
   • Procedure – This value associates an existing procedure with the subType. To add a procedure, click the Select link and select a procedure from the list. Procedures are created through the Knowledge module and indicate the steps needed to perform an aspect of the work requested. If a procedure is specified for a subType, new work orders created with this subType will automatically be associated with the procedure. However, this functionality does not pertain to work orders created using the Schedule module. For more information, see Creating Procedures.
   • Default Labor Activity – This value indicates the default type of labor associated with the subType. This value is displayed on the Work Order Financial page of the request details as the default labor activity. For more information, see Labor Activity Codes.
   • Service Type – This value indicates the type of service being performed.

6. To further define the subType, display the detail fields by selecting the Show Detail check box.

7. Modify any of the following values:

   • External SubType ID – This value allows you to define/modify a mapping to a request subType ID in an external system. External system interfaces will first search for matches based on external system IDs and, if there is no match, it will search on External System Name.
   • GL Account A/R, GL Contra Labor, and GL Account Labor – These values indicates fields to hold default values for the general ledger. Primarily used when interfacing with external systems.
   • Allow Markup – Indicates whether markup is allowed when specifying labor and materials costs on the Work Order Financial page of the request details
   • Work Order Form – Attaches a work order form to requests of this subType. When creating a request with an attached work order form, a window prompting for additional fields of information is displayed when the work request is created. For more information, see Work Order Forms Format.
   • Charge To Setting – Allows you to select a group of charge codes to be associated with the subType so that users can only select from codes in a specific group when selecting a Charge To value on the Work Order Financial page of the request details.
   • Spend Category and Commodity Code –Text fields to hold default values for cost values. Primarily used when interfacing with external systems.
   • Cost Code Group – Allows you to select a cost code group to be associated with the subType so that users can only select from cost codes in a specific group when closing the work order. This feature is not widely used by the majority of installations.
   • Notify Requestor on Update – Allows you to select the default state of the Notify Requestor check box when updating the work request. Additionally, if notifications are sent, you can select whether email or text responses to the notification email are sent to the requestor via email. Select one of the following values:
     
     • No – Indicates that the check box is not selected by default. The user can change this value.
     • No, Read Only– Indicates that the check box is not selected by default. The check box is grayed out so that the user cannot change this value.
     • Yes, with Email Updates – Indicates that the check box is selected by default. In addition, email or text responses to the notification email update the request and are forwarded to the requestor.
     • Yes, without Email Updates – Indicates that the check box is selected by default. In addition, email or text responses to the notification email update the request but are not forwarded to the requestor.

     This default value can be changed by the user updating the work request unless No, Read Only is selected.

8. Once the subType has been defined, click UPDATE to save all changes.

Existing request types can be edited. To edit a request type:

1. In the Request Type field, select a request type.

   The detail fields appear as well as a list of the defined subTypes.

2. To modify the request type definition, modify any of the displayed fields and click UPDATE.

   For information about the displayed fields, see Add a New Request Type, step 5.

Existing request subTypes can be edited. To edit a request subType:

1. In the Request Type field, select the request type that the subType was created beneath.

   The detail fields appear as well as a list of the defined subTypes.

2. In the Request SubTypes pane of the page, modify any of the displayed fields and click UPDATE.

   For information about the displayed fields, see Add a New Request SubType, step 5 or Add a New Request SubType, step 7.

If it is no longer needed, a request type can be deleted from the system. A request type cannot be deleted if it has any subTypes associated with it or if it is has an activity group associated with it. To delete a request type:

1. In the Request Type field, select the request type you want to delete.

   The detail fields for the request type appear.

2. If the request type has any subTypes associated with it, delete all subTypes.

   For more information, see Delete a Request SubType.

3. If the request type has an activity group associated with it, delete the association.

   For more information, see Activity Group – Delete a Request Type.

4. Click DELETE.

   A dialog box opens asking you to confirm your choice.

5. Click OK.

If it is no longer needed, a request subType can be deleted from the request type. To delete a request subType:

1. In the Request Type field, select the request type that the subType was created beneath.

   The detail fields for the request type appear as well as a list of the defined subTypes.

2. In the yellow pane, locate the subType you want to delete and click DELETE.

Request types can only be used at the properties they are associated with. The Other Options pane allows super administrators to propagate a request type to all properties in a region. Performing this function is equivalent to opening the Property Requests Types page and selecting this request type for each property in the region.

To propagate request types to all properties in a region:

1. Open the Other Options pane.

2. To the right of the Propagate this Request Type to Properties in this Region label, click the Select link.

   A dialog box opens allowing you to select a region.

3. Locate and select the desired region.

4. Click UPDATE.

   A dialog box opens asking you to confirm your choice.

5. Click OK.